The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Information based on or derived from a set of related data items are commonly presented to users as a collection of views. For example, information about an individual contact, email, or search hit may be displayed as an individual element, or “view,” in a scrollable list of contacts, emails, or search hits. The information inside each data item is used to generate, or “render,” a displayable view based on the data item. For example, information about a contact may be rendered as one or more Hyper-text Markup Language (“HTML”) elements in a web application.
Rendering views for collections of items can be a resource-intensive process. This is true both from the perspective of the amount of memory necessary to store the rendered views in comparison to the amount of memory necessary to store views of items, and from the perspective of processor utilization during the rendering. For example, at the time of writing, interaction with the Document Object Model (“DOM”) to generate HTML elements is notoriously expensive from both memory and processor perspectives. Naturally, the amount of resource usage necessary to render an entire collection of views grows in proportion to the size of the collection.
One technique for dealing with various complications arising from the high resource utilization involved in rendering collections of items is to render views, when possible, at the client responsible for displaying the view as opposed to a server. This technique helps confront potentially incapacitating issues such as delays stemming from latency between the client and the server, and/or constraints on bandwidth between the client and the server. However, the technique does nothing to address the issue of memory limitations at the client. This technique also shifts processor utilization to the client, where, depending on the natures of the client application and the client device, the detrimental effects of higher processor utilization may include decreased battery life and/or perceivable, albeit typically less pronounced, delays or “jerkiness” while the client renders the views.
Another technique for dealing with various complications arising from the high resource utilization involved in rendering collections of items is to only render views that are positioned within the viewable window of an arrangement. An application determines when an operation modifies the views that are within a viewable window. The application determines which views are no longer within the viewable window and deletes them. The application also determines which items should now have views in the viewable window, and renders views for any items that were not displayed prior to the operation. In this manner, the application is able to permanently decrease memory utilization. However, this benefit comes with the requirement of higher processor utilization during even short-distance scrolling operations. Higher processor utilization during operations that modify the viewable window is often undesirable. For example, in devices such as mobile phones, bursts of higher processor utilization as the user scrolls through a list negatively affect the “smoothness” of the operation, as perceived by the user.